@SamuelMarks just released rust info and git info

question about diesel. why do we need it integrated to cargo-make? that feels like implementation details to something you will use outside of cargo-make.
if execution plan is serializable to json, just serialize and insert that. why do i need diesel stuff all over the codebase?

@sagiegurari It's annoying that diesel has to be depended on. AFAIK directly decorating structs of the first-party crate with derive annotations is the only way—aside from hacky nom rereads at debug-time so that a reflection style system is imposed.

Not even sure embedded types would solve this. The only obvious solution is to store struct records as JSON in a column of the SQL table. But what if I want an ExecutionPlan table? - And a Step table? - And a table joining the two that also includes State column, something like datetime stopped(Option<error>); datetime started; datetime scheduled

PS: This PR is almost ready for merge IMHO, just a little bit more rendering around the edges TODO.

Just trying to get the full demo in place:

1 . TOML → saved somewhere (e.g., flat-file JSON or database)
2. While not at end task:
a. Saved somewhere → logic to determine what step range to execute (if None then sleep and try later)
b. Execute found step range (e.g., before_each, task_name, after_each)
c. Update file || db with new status
3. Execute end task

(these steps could for example be executed in parallel and on multiple machines)

AND importantly I want to get this workflow supported without dramatically changing cargo-make. Just a little smattering of good stuff atop (error handling; use-as-library; serialising/deserialising & diesel derived types; and minor ergonomic improvements). cargo-make main use-case remains a Makefile alternative not a new Apache Airflow!

@SamuelMarks how about first you get some demo working for you than when you get a final understanding of what you need to make it work for you, revisit this PR and see the bare minimum needed for cargo-make to change to support it.
i prefer not to

1. push diesel dependencies - any change i do to the structs will break peoples stuff - use json or other deserializers which could than be columnized (is it a word?)
2. all the changes apart of that, are also kinda spooky. not sure i fully get them and why they need to be part of cargo make. for example execution plan is just a list of steps. you want also the range? have an executionplanwithstate or something and improve the runner to use that.

in general, i do'nt want to couple entire execution and structs to something very specific you are building. i want to enable extensions but not hard coupling.

@sagiegurari Ok I've converted this to draft whilst I get it into a working state. Not long now [hopefully]!

The main issue with only supporting serde seems to be representing structs as tables in diesel. Explicitly when you add, remove, or change a struct field in cargo-make I don't want to have to update my codebase. This is explicitly coupled to your implementation.

Anyway watch this space! - Probably 24 to 48 hours away.